技术分享 | 使用备份恢复实例时存在的坑

作者：林靖华

爱可生服务团队成员，负责处理客户在MySQL日常运维中遇到的问题；擅长处理备份相关的问题，对数据库相关技术有浓厚的兴趣，喜欢钻研各种问题。

本文来源：原创投稿

*爱可生开源社区出品，原创内容未经授权不得随意使用，转载请联系小编并注明来源。

---

前言

在日常数据库运维中，备份是不可缺少的一部分。我们常常用备份集来新建从库或恢复数据不一致的实例等等。但有些时候恢复完实例加回集群后，是有可能会丢失数据的。

实验

环境准备

步骤

1、主从同步验证

先在主库写入一些数据，然后验证数据已经同步到从库

1. -- master(131)

2. mysql> create database test1;

3. Query OK, 1 row affected (0.00 sec)

4. mysql> create database test2;

5. Query OK, 1 row affected (0.01 sec)

6. mysql> show databases;

7. +--------------------+

8. | Database |

9. +--------------------+

10. | information_schema |

11. | mysql |

12. | performance_schema |

13. | sys |

14. | test1 |

15. | test2 |

16. +--------------------+

17. 6 rows in set (0.00 sec)

18. mysql> show master status;

19. +------------------+----------+--------------+------------------+------------------------------------------+

20. | File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |

21. +------------------+----------+--------------+------------------+------------------------------------------+

22. | mysql-bin.000001 | 478 | | | eefac7d8-2370-11e9-bfeb-000c29d74445:1-2 |

23. +------------------+----------+--------------+------------------+------------------------------------------+

24. 1 row in set (0.00 sec)

25. -- slave(132)

26. mysql> show databases;

27. +--------------------+

28. | Database |

29. +--------------------+

30. | information_schema |

31. | mysql |

32. | performance_schema |

33. | sys |

34. | test1 |

35. | test2 |

36. +--------------------+

37. 6 rows in set (0.00 sec)

38. mysql> show slave status\G;

39. *************************** 1. row ***************************

40. Slave_IO_State: Waiting for master to send event

41. Master_Host: 192.168.13.131

42. Master_User: repl

43. Master_Port: 3306

44. Connect_Retry: 60

45. Master_Log_File: mysql-bin.000001

46. Read_Master_Log_Pos: 478

47. Relay_Log_File: 192-168-13-132-relay-bin.000002

48. Relay_Log_Pos: 691

49. Relay_Master_Log_File: mysql-bin.000001

50. Slave_IO_Running: Yes

51. Slave_SQL_Running: Yes

52. ......

53. Retrieved_Gtid_Set: eefac7d8-2370-11e9-bfeb-000c29d74445:1-2

54. Executed_Gtid_Set: eefac7d8-2370-11e9-bfeb-000c29d74445:1-2

2、 在从库上创建备份

逻辑备份或物理备份都可以，这里以逻辑备份为例

1. mysqldump -uroot -p123456 --single-transaction --master-data=2 --all-databases > dump.sql

3、向主库写入数据

1. -- master(131)

2. mysql> create database test3;

3. Query OK, 1 row affected (0.00 sec)

4. mysql> show databases;

5. +--------------------+

6. | Database |

7. +--------------------+

8. | information_schema |

9. | mysql |

10. | performance_schema |

11. | sys |

12. | test1 |

13. | test2 |

14. | test3 |

15. +--------------------+

16. 7 rows in set (0.01 sec)

17. mysql> show master status;

18. +------------------+----------+--------------+------------------+------------------------------------------+

19. | File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |

20. +------------------+----------+--------------+------------------+------------------------------------------+

21. | mysql-bin.000001 | 640 | | | eefac7d8-2370-11e9-bfeb-000c29d74445:1-3 |

22. +------------------+----------+--------------+------------------+------------------------------------------+

23. 1 row in set (0.00 sec)

24. -- slave(132)

25. mysql> show databases;

26. +--------------------+

27. | Database |

28. +--------------------+

29. | information_schema |

30. | mysql |

31. | performance_schema |

32. | sys |

33. | test1 |

34. | test2 |

35. | test3 |

36. +--------------------+

37. 7 rows in set (0.00 sec)

38. mysql> show slave status\G;

39. *************************** 1. row ***************************

40. Slave_IO_State: Waiting for master to send event

41. Master_Host: 192.168.13.131

42. Master_User: repl

43. Master_Port: 3306

44. Connect_Retry: 60

45. Master_Log_File: mysql-bin.000001

46. Read_Master_Log_Pos: 640

47. Relay_Log_File: 192-168-13-132-relay-bin.000002

48. Relay_Log_Pos: 853

49. Relay_Master_Log_File: mysql-bin.000001

50. Slave_IO_Running: Yes

51. Slave_SQL_Running: Yes

52. ......

53. Retrieved_Gtid_Set: eefac7d8-2370-11e9-bfeb-000c29d74445:1-3

54. Executed_Gtid_Set: eefac7d8-2370-11e9-bfeb-000c29d74445:1-3

4、产生故障

假设现在主库存放数据的磁盘发生故障，HA 将原来的从节点提升为主节点来提供数据的写入，然后插入数据

1. -- new master(132)

2. mysql> create database test4;

3. Query OK, 1 row affected (0.01 sec)

4. mysql> show databases;

5. +--------------------+

6. | Database |

7. +--------------------+

8. | information_schema |

9. | mysql |

10. | performance_schema |

11. | sys |

12. | test1 |

13. | test2 |

14. | test3 |

15. | test4 |

16. +--------------------+

17. 8 rows in set (0.00 sec)

18. mysql> show master status;

19. +------------------+----------+--------------+------------------+----------------------------------------------------------------------------------+

20. | File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |

21. +------------------+----------+--------------+------------------+----------------------------------------------------------------------------------+

22. | mysql-bin.000001 | 802 | | | b66b4623-207d-11ea-a993-000c29122c12:1,

23. eefac7d8-2370-11e9-bfeb-000c29d74445:1-3 |

24. +------------------+----------+--------------+------------------+----------------------------------------------------------------------------------+

25. 1 row in set (0.00 sec)

5、恢复实例

用之前备份的数据来恢复挂掉的实例

1. -- old master(131)

2. mysql -uroot -p123456 < dump.sql

恢复后拥有的数据

1. mysql> show databases;

2. +--------------------+

3. | Database |

4. +--------------------+

5. | information_schema |

6. | mysql |

7. | performance_schema |

8. | sys |

9. | test1 |

10. | test2 |

11. +--------------------+

12. 6 rows in set (0.00 sec)

13. mysql> show master status;

14. +------------------+----------+--------------+------------------+------------------------------------------+

15. | File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |

16. +------------------+----------+--------------+------------------+------------------------------------------+

17. | mysql-bin.000001 | 478 | | | eefac7d8-2370-11e9-bfeb-000c29d74445:1-2 |

18. +------------------+----------+--------------+------------------+------------------------------------------+

19. 1 row in set (0.00 sec)

6、与新主建立复制关系

1. -- old master(131)

2. mysql> change master to

3. -> master_host='192.168.13.132',

4. -> master_user='repl',

5. -> master_password='123456',

6. -> master_auto_position=1;

7. Query OK, 0 rows affected, 2 warnings (0.01 sec)

8. mysql> start slave;

9. Query OK, 0 rows affected (0.00 sec)

10. mysql> show databases;

11. +--------------------+

12. | Database |

13. +--------------------+

14. | information_schema |

15. | mysql |

16. | performance_schema |

17. | sys |

18. | test1 |

19. | test2 |

20. | test4 |

21. +--------------------+

22. 7 rows in set (0.00 sec)

23. mysql> show master status;

24. +------------------+----------+--------------+------------------+----------------------------------------------------------------------------------+

25. | File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |

26. +------------------+----------+--------------+------------------+----------------------------------------------------------------------------------+

27. | mysql-bin.000001 | 640 | | | b66b4623-207d-11ea-a993-000c29122c12:1,

28. eefac7d8-2370-11e9-bfeb-000c29d74445:1-2 |

29. +------------------+----------+--------------+------------------+----------------------------------------------------------------------------------+

30. 1 row in set (0.00 sec)

现象

可以观察到，在旧主通过备份恢复数据且加回到集群后，丢失了部分的数据。操作的步骤看起来并没有问题，那么原因是什么呢？

丢失的事务的 GTID 是 eefac7d8-2370-11e9-bfeb-000c29d74445:3，我们先到新主的 binlog 中看下是否还有这个事务的记录，保证 binlog 没有被清理。

1. #200220 14:19:41 server id 1 end_log_pos 543 CRC32 0x3fa9fb8c GTID last_committed=2 sequence_number=3 rbr_only=no

2. SET @@SESSION.GTID_NEXT= 'eefac7d8-2370-11e9-bfeb-000c29d74445:3'/*!*/;

3. # at 543

4. #200220 14:19:41 server id 1 end_log_pos 640 CRC32 0x8427b0a3 Query thread_id=4 exec_time=0 error_code=0

5. SET TIMESTAMP=1582179581/*!*/;

6. create database test3

7. /*!*/;

新主的 binlog 中是有这个事务的，那接着我们再来看下旧主的 relaylog 中是否也同样记录。但意外的是，relaylog 中并没有相关的记录，说明这个事务根本没有写进 relaylog。

那么我们可以回想一下，在 MySQL 里面，有没有类似的机制或者参数让主库的 binlog 在传输或写入从库的过程中被过滤掉。正好我们发现，开启 binlog 必须要配置的 server_id 就能起到这样的作用。

分析

由于我们在恢复实例的时候使用的备份集不是最新的备份集，这个备份集中只含有 eefac7d8-2370-11e9-bfeb-000c29d74445:1-2 两个事务，那么恢复回来的实例加入集群变成从实例的时候，需要通过新主库的 binlog 来补偿数据。

在传输事务 eefac7d8-2370-11e9-bfeb-000c29d74445:3 的时候，从实例的 io_thread 发现这个事务记录的 server_id 为 1，与自己的 server_id 一致，会认为这个是自己执行过的事务，就会把这段信息给过滤掉，最终这个从实例的数据就会缺少一部分。

总结

由此可见，在这种情况下，更换 server_id 是最简单的解决办法，所以我们在恢复实例的时候，尽可能的去修改 server_id，保证 server_id 不与之前的重复且与集群中的其他实例不相同。

有不少人并没有碰到类似的问题，是因为他们在恢复实例的时候，通常是直接在线备份线上的实例，用最新的备份集来导入数据，在这种情况下，也可以避免以上问题的发生。

另外还有一个值得一提的参数 --replicate-same-server-id，这个参数的作用是开启后即使 io_thread 收到与自己 server_id 相同的 binlog，也会写入 relaylog。虽然启用这个参数也可以避免以上问题，但在大部分情况下都不推荐开启这个参数，默认值 OFF 是为了避免 binlog 在复制中回环。在 5.7 中想开启这个参数的话需要先关闭 log_slave_updates；8.0 则做了改进，当 gtid_mode=ON 的情况下就可以开启。

参考：

https://lefred.be/content/mysql-gtid-restore-a-master-from-a-replicas-backup/ https://www.zhangshengrong.com/p/yOXD5zZM1B/ https://dev.mysql.com/doc/refman/5.7/en/replication-options-slave.html#optionmysqldreplicate-same-server-id

社区近期动态

 点一下“阅读原文”了解更多资讯